home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Tech Arsenal 1
/
Tech Arsenal (Arsenal Computer).ISO
/
tek-20
/
nosvw304.zip
/
NOSGAS.ZIP
/
PUBLIC
/
NOSVIEW
/
TCP
< prev
next >
Wrap
Text File
|
1991-09-18
|
14KB
|
286 lines
=== NOSview [137]
tcp
===
The 'tcp' commands are used for the Transmission Control Protocol
(TCP) service.
_________________________________________________________________
tcp irtt [<milliseconds>] Default: 5000
_________________________________________________________________
Display or set the initial-round-trip-time (IRTT) estimate, to be
used for new TCP connections until they can measure and adapt to
the actual value.
Increasing the value of IRTT when operating over slow channels
will avoid the flurry of retransmissions that would otherwise
occur as the smoothed estimate settles down at the correct value.
Note that this command should be given before servers are started
in order for it to have effect on incoming connections.
TCP also keeps a cache of measured round trip times and mean
deviations (MDEV) for current and recent destinations. Whenever
a new TCP connection is opened, the system first looks in this
cache. If the destination is found, the cached IRTT and MDEV
values are used. If not, the default IRTT value mentioned above
is used, along with a MDEV of 0. This feature is fully automatic,
and it can improve performance greatly when a series of
connections are opened and closed to a given destination (e.g. a
series of FTP file transfers or directory listings).
>> Example: tcp irtt 5000
_________________________________________________________________
tcp kick <&TCB>
_________________________________________________________________
If there is unacknowledged data on the send queue of the
specified Transmission Control Block (TCB), this command forces
an immediate retransmission. The TCB address <&TCB> can be
determined from the 'tcp status' command.
>> Example: tcp kick 83360008
_________________________________________________________________
tcp mss [<bytes>] Default: 512
_________________________________________________________________
Display or set the TCP Maximum Segment Size (MSS). MSS is
parameter that limits the amount of data that the remote TCP will
send in a single TCP packet. MSS values are exchanged in the SYN
(connection request) packets that open a TCP connection.
In the NOS implementation of TCP, the MSS actually used by TCP is
further reduced in order to avoid fragmentation at the local IP
interface. That is, the local TCP asks IP for the MTU of the
interface that will be used to reach the destination. It then
subtracts 40 from the MTU value to allow for the overhead of the
TCP and IP headers. If the result is less than the MSS received
from the remote TCP, it is used instead.
The setting of this TCP-level parameter is somewhat less critical
than the IP MTU and AX.25 <paclen> parameters, mainly because it
is automatically lowered according to the MTU of the local
interface when a connection is created, as described above.
Although this is, strictly speaking, a protocol layering
violation (TCP is not supposed to have any knowledge of the
workings of lower layers) this technique does work well in
practice.
However, it can be fooled; for example, if a routing change
occurs after the connection has been opened and the new local
interface has a smaller MTU than the previous one, IP
fragmentation may occur in the local system.
The only drawback to setting a large MSS is that it might cause
avoidable fragmentation at some other point within the network
path if it includes a "bottleneck" subnet with an MTU smaller
than that of the local interface. (Unfortunately, there is
presently no way to know when this is the case. There is ongoing
work within the Internet Engineering Task Force on an "MTU
Discovery" procedure to determine the largest datagram that may
be sent over a given path without fragmentation, but this work is
not yet complete).
Also, since the MSS you specify is sent to the remote system, and
not all other TCPs do the MSS-lowering procedure yet, this might
cause the remote system to generate IP fragments unnecessarily.
On the other hand, a too-small MSS can result in a considerable
performance loss, especially when operating over fast LANs and
networks that can handle larger packets.
So the best value for MSS is probably 40 less than the largest
MTU on your system, with the 40-byte margin allowing for the TCP
and IP headers. For example, if you have a SLIP interface with a
1006 byte MTU and an Ethernet interface with a 1500 byte MTU, set
MSS to 1460 bytes. This allows you to receive maximum-sized
Ethernet packets, assuming the path to your system does not have
any bottleneck subnets with smaller MTUs.
An MSS of 216 corresponds to the MTU of 256 set up in AX.25
'attach' commands.
Changing MSS affects only future connections; existing
connections are unaffected.
>> Examples: tcp mss 216 (for an AX.25-only system)
tcp mss 966 (for a SLIP system)
tcp mss 1460 (for an Ethernet or PPP system)
_________________________________________________________________
tcp reset <&TCB>
_________________________________________________________________
Deletes the TCP control block at the specified address <&TCB>.
>> Example: tcp reset 83360008
_________________________________________________________________
tcp rtt <&TCB> <milliseconds>
_________________________________________________________________
Replaces the automatically computed round-trip-time in the
specified TCB with the rtt in milliseconds. This command is
useful to speed up recovery from a series of lost packets since
it provides a manual bypass around the normal backoff
retransmission timing mechanisms.
>> Example: tcp rtt 83360008 3000
_________________________________________________________________
tcp status [<&TCB>]
_________________________________________________________________
Without arguments, displays several TCP-level statistics, plus a
summary of all existing TCP connections, including TCB address,
send and receive queue sizes, local and remote sockets, and
connection state.
If <&TCB> is specified, a more detailed dump of the specified TCB
is generated, including send and receive sequence numbers and
timer information.
>> Example of 'tnc status' output:
...............................................................
: :
:( 1)tcpRtoAlgorithm 4 ( 2)tcpRtoMin 0:
:( 3)tcpRtoMax 4294967295 ( 4)tcpMaxConn 4294967295:
:( 5)tcpActiveOpens 2 ( 6)tcpPassiveOpens 2:
:( 7)tcpAttemptFails 0 ( 8)tcpEstabResets 0:
:( 9)tcpCurrEstab 4 (10)tcpInSegs 10:
:(11)tcpOutSegs 10 (12)tcpRetransSegs 0:
:(14)tcpInErrs 0 (15)tcpOutRsts 0:
: :
: &TCB Rcv Snd Local socket Remote socket State :
: Q Q :
:858c0008 0 0 ns9bob:ftp ns9ken:1025 Established :
:85050008 0 0 ns9bob:1025 ns9liz:ftp Established :
:841f0008 0 0 0.0.0.0:ftp 0.0.0.0:0 Listen (S) :
:83360008 0 0 ns9bob:telnet ns9liz:1024 Established :
:7d530008 0 0 ns9bob:1024 ns9jim:telnet Established :
:840d0008 0 0 0.0.0.0:telnet 0.0.0.0:0 Listen (S) :
:845b0008 0 0 0.0.0.0:ttylink 0.0.0.0:0 Listen (S) :
:84400008 0 0 0.0.0.0:finger 0.0.0.0:0 Listen (S) :
:84310008 0 0 0.0.0.0:smtp 0.0.0.0:0 Listen (S) :
:83fb0008 0 0 0.0.0.0:discard 0.0.0.0:0 Listen (S) :
:83ec0008 0 0 0.0.0.0:echo 0.0.0.0:0 Listen (S) :
:.............................................................:
>> Example of 'tcp status 83360008' output:
...............................................................
:Local: ns9bob:telnet Remote: ns9liz:1024 State: Established :
: Init seq Unack Next Re- CW Thrsh Wind MSS Q Total :
: sent ind :
:Send: 2b66000 2b66026 2b66026 0 216 65535 216 216 0 37 :
:Recv: 2b66000 2b66001 0 216 0 0 :
:Timer stopped SRTT 49779 ms Mean dev 26384 ms :
:.............................................................:
_________________________________________________________________
tcp syndata [on|off] Default: off
_________________________________________________________________
Display or set the "syndata" flag. When set to 'on', SYN and
data are piggybacked. This reduces transmission time, as the
sending end does not have to wait for an acknowledgement to the
SYN before sending data.
>> Example: tcp syndata on
_________________________________________________________________
tcp timertype [linear|exponential]
_________________________________________________________________
The TCP timer backoff can be either linear or binary exponential.
Linear backoff is recommended for amateur radio work.
>> Example: tcp timertype linear
_________________________________________________________________
tcp trace [on|off] Default: off
_________________________________________________________________
Display or set TCP trace mode. When set to 'on', task control
block activity is displayed, together with numbered TCP protocol
messages.
>> Example: tcp trace on
ftp ns9aaa
produces an output of the form:
...............................................................
: :
:TCB 862b0008 Closed -> SYN sent :
:TCB 89d90008 Listen -> SYN received :
:Resolving ns9aaa... Trying ns9aaa:ftp... :
:TCB 862b0008 SYN sent -> Established :
:FTP session 3 connected to ns9aaa :
:TCB 89d90008 SYN received -> Established :
:220 ns9aaa FTP version 910618 (PA0GRI v1.7a) ready .... :
:Enter user name: helen :
:331 Enter PASS command :
:Password: :
:230 Logged in :
:ftp> pwd :
:257 "/nos/public" is current directory :
:.............................................................:
_________________________________________________________________
tcp window [<bytes>] Default: 2048
_________________________________________________________________
Displays or sets the default receive window size. This is a TCP-
level parameter that controls how much data the local TCP will
allow the remote TCP to send before it must stop and wait for an
acknowledgement.
If the window size is twice as big as the Maximum Segment Size
(MSS), for example, there will be two active packets on the
channel at any given time. Large values of window size provide
improved throughput on full-duplex links, but are a problem on
the air.
The actual window value used by TCP when deciding how much more
data to send is referred to as the effective window. This is the
smaller of two values: the window advertised by the remote TCP
minus the unacknowledged data in flight, and the congestion
window, an automatically computed time-varying estimate of how
much data the network can handle.
In most cases it is safe to set the TCP window to a small integer
multiple of the MSS (e.g. 4 times), or larger if necessary to
fully utilize a high bandwidth*delay product path. One thing to
keep in mind, however, is that advertising a certain TCP window
value declares that the system has that much buffer space
available for incoming data. NOS does not actually preallocate
this space; it keeps it in a common pool and may well "overbook"
it, exploiting the fact that many TCP connections are idle for
long periods and gambling that most applications will read
incoming data from an active connection as soon as it arrives,
thereby quickly freeing the buffer memory.
However, it is possible to run NOS out of memory if excessive TCP
window sizes are advertised and either the applications go to
sleep indefinitely (e.g. suspended Telnet sessions) or a lot of
out-of-sequence data arrives. It is wise to keep an eye on the
amount of available memory and to decrease the TCP window size
(or limit the number of simultaneous connections) if it gets too
low.
Depending on the channel access method and link level protocol,
the use of a window setting that exceeds the MSS may cause an
increase in channel collisions. In particular, collisions
between data packets and returning acknowledgements during a bulk
file transfer may become common. Although this is, strictly
speaking, not TCP's fault, it is possible to work around the
problem at the TCP level by decreasing the window so that the
protocol operates in stop-and-wait mode. This is done by making
the window value equal to the MSS.
In summary, therefore, keep MSS <= window <= 2*MSS for half-
duplex radio links.
>> Example: tcp window 216